Metering the usage of software programs in a data processing system is of the utmost importance in several management infrastructures. A typical example consists of a license management application, which is used to collect information about known programs running on the system (for example, for charge-back accounting). A commercial license management application available on the market is the “IBM Tivoli License Manager (ITLM)” by IBM Corporation.
Generally, the license management application monitors the processes that are active on the system (for example, by retrieving a list of the active processes periodically or by intercepting the starting of every new process). The program associated with each active process is then identified by comparing its characteristics with predefined signatures of all the known programs to be metered (stored in a software catalogue); generally, each signature specifies one or more attributes (such as name and size) of an executable module associated with the active process (which running indicates the usage of the corresponding program).
A problem of the licensing management applications is the identification of the programs that are interpreted. As it is well known, an interpreted program consists of a series of instructions (written in a high-level language), which instructions are executed one at a time by an interpreter; the interpreted programs differ from compiled programs, which are previously converted by a compiler into machine code being directly executable on the system. The interpreted programs are particular attractive in open architectures, since they can be executed on different hardware and/or software platforms (provided that a corresponding interpreter is available). A typical example is that of programs written in the Java language, which programs are executed by a Java Virtual Machine (JVM).
However, when the Java programs are executed, the corresponding active process is only the one associated with the JVM; therefore, the above-described solution detects the usage of the JVM, but it is completely unable to identify the Java programs that are executed by the JVM.
In order to solve this problem, in the current practice the Java programs are instrumented with a Java toolkit being provided by the licensing management application; in this way, each Java program is updated to include a call to the licensing management application for notifying its start and stop. However, this solution is ineffective to detect the usage of all the other Java programs that are not expressly instrumented.
Another solution is that of exploiting profiling and/or debugging capabilities of some JVMs—such as the Virtual Machine Profiler Interface (JVMPI) and the Virtual Machine Debug Interface (JVMDI). However, the above-mentioned interfaces are not standard, so that they are not always available; moreover, this approach interferes with the execution of the Java programs (with a deleterious effect on their performance).
Co-pending patent application US-A-2005/0268290 instead proposes identifying the Java programs by means of the native functions that are invoked by the JVM for communicating with the underlying system—via the Java Native Interface (JNI); typically, these native functions are used to load any new class of the Java programs. For this purpose, a stub library is loaded in place of each dynamic library implementing the native functions required to load the new class; the stub library identifies the Java program that requested the loading of the new class by means of a software catalogue that associates each Java program with one or more corresponding classes. In a different embodiment, a stub class loader detects the loading of the class including a main method, which typically defines an entry point of any Java program. The main method is then updated by injecting a call to the licensing management application; as above, it is possible to identify the Java program by means of the class on which the main method was invoked (passed as an argument to the licensing management application by the injected call).
However, the above-described solution is not completely satisfactory. Indeed, when two or more different Java programs (or versions thereof) load a common class used for their identification, the licensing management application is unable to discriminate the one that is currently executed. Moreover, the proposed implementation based on the stub class loader requires updating the code of the class including the main method. Therefore, this approach is quite invasive, and it may cause unexpected malfunctioning.
All of the above prevents carrying out a full control of the interpreted programs that are executed. In the specific example at issue, this has a deleterious effect on the accuracy of the metering performed by the license management applications; the problem is particular acute in modern data processing systems (such as based on the Internet), wherein interpreted programs (and particularly Java programs) represent a large share of the market.